Il down più discusso dello scorso 5 ottobre fa riflettere su quanto un’azienda o un business abbia bisogno di più “vie d’uscita” in caso di emergenza.
Ovviamente il blackout a cui facciamo riferimento è quello che ha interessato la piattaforma “Facebook” che ha tenuto milioni di utenti con il fiato sospeso per più di sei ore. A mandare in tilt non solo il social network, ma tutta l’azienda Facebook tutta è stato un errore che ha dato vita ad un serie di interruzioni nel sistema e che ha impedito non solo l’accesso degli utenti alla piattaforma, ma anche disservizi ed inattività ai dipendenti . Quello su cui vorremmo soffermarci è “Quanto un’azienda può essere dipendente da un solo single point of failure?”
Cos’è un Single Point of Failure?
Partiamo col definire un Single Point of Failure.
“Uno SPOF o singolo punto di errore è qualsiasi parte non ridondante di un sistema che, se disfunzionale, può causare il guasto dell’intero sistema. Un singolo punto di errore è antitetico all’obiettivo dell’alta disponibilità in un sistema informatico o in una rete, un’applicazione software, una pratica aziendale o qualsiasi altro sistema industriale.”
La domanda sorge, quindi, spontanea… Come si può evitare?
Eliminare i SPOF nel Cloud Computing
Ridondanza e cluster ad alta disponibilità sono la chiave dei fattori per evitare gli SPOF. Sia ridondanza logica che ridondanza fisica. I cluster ad alta disponibilità riducono al minimo le interruzioni (99,99%disponibilità) dei componenti di sistema inclusi nel Cloud.
La ridondanza fisica può essere ottenuta con un’elevata disponibilità cluster. Nessun hardware o software dovrebbe fare affidamento su un singolo hardware in ogni caso. È essenziale mitigare il server come altamente disponibile nel Cloud migliorando l’architettura fisica con più router e switch. L’architettura del Data Center dovrebbe garantire la ridondanza fisica in modo tale da evitare la comunicazione unidirezionale tra il Cloud e le componenti del sistema.
Cos’è il Disaster Recovery plan e quali sono i vantaggi?
L’interruzione improvvisa di un’insieme di servizi legati tutti ad un’unica configurazione può far riflettere su quanto sia diventato importante avere sempre un piano di emergenza che possa essere adottato in situazioni improvvise, ma soprattutto imprevedibili. Basti pensare a catastrofi naturali come terremoti, maremoti, incendi che possono abbattersi su un business e lasciare senza via di scampo.
Il Disaster Recovery Plan è un processo relativo alla preparazione per il recupero e la continuità dei servizi vitali di un’impresa dopo un evento naturale o per un errore umano. È composto da un insieme di fasi tra cui:
Testing: Dopo aver installato la soluzione DR, è necessario testarla. “Game day” è quando si esegue un failover nell’ambiente DR.
Monitoring and Alerting: È necessario disporre di controlli regolari e di un monitoraggio sufficiente per avvisare l’utente nel caso il proprio ambiente DR sia stato interessato da guasti del server, problemi di connettività e problemi applicativi.
Backups: Una volta implementato l’ambiente DR, è necessario continuare a eseguire backup regolari. Test di backup e ripristino periodici sono essenziali come soluzione di ripiego.
User Access: È possibile proteggere l’accesso alle risorse nel proprio ambiente DR utilizzando AWS Identity and Access Management (IAM).
Automation: È possibile automatizzare la distribuzione di applicazioni sui server basati su AWS e sui server locali utilizzando il software di gestione della configurazione.